Conversation
This is actually a workaround. The real issue is that timer at the moment are completely outside of the data streaming and therefore do not have access to the DataTakingService, where the proper calculation for the run number happens and it's cached. OK for now. In the future we should make sure that the LifetimeHelpers::enumerate gets a "Streaming" context, not the global one.
|
REQUEST FOR PRODUCTION RELEASES: This will add The following labels are available |
|
@ehellbar can you suggest a range of Run Numbers to use for special meanings (e.g. errors?)? Where is the list of the currently reserved numbers? |
|
Hi @ktf, most of the messages are gone, but there seem to be still a few sources of DataHeaders with run number 0 left. We get messages from ITS and MFT QC proxies during the run, and the usual barrage of messages at the end of a run. Tests on STG (using custom without this PR, run 1819: 2.44 per second + 182 after STOP (http://alio2-cr1-hv-mvs00.cern.ch:8081/?q={%22run%22:{%22match%22:%221819%22},%22message%22:{%22match%22:%22%25INVALID%20run%25%22},%22severity%22:{%22in%22:%22E%20F%22}}) with this PR, run 1822: 0.08 per second + 182 after STOP (http://alio2-cr1-hv-mvs00.cern.ch:8081/?q={%22partition%22:{%22match%22:%222tq5oUHUzUW%22},%22message%22:{%22match%22:%22%25INVALID%20run%25%22},%22severity%22:{%22in%22:%22E%20F%22}}) NB: these are on FLPs on STG. In PROD, we also see messages on EPNs at the end of run which we don't see on STG. |
3 participants
This is actually a workaround. The real issue is that timer at the moment are
completely outside of the data streaming and therefore do not have access to
the DataTakingService, where the proper calculation for the run number happens
and it's cached.
OK for now.
In the future we should make sure that the LifetimeHelpers::enumerate
gets a "Streaming" context, not the global one.